The number of organizations and enterprises that expose their business information and services on the Internet has rapidly increased. Online banking and shopping services are merely a couple of examples for popular web applications. Web applications, or services, are facilitated through a datacenter, which typically, as illustrated in FIG. 1, includes web servers 110, an application delivery controller (ADC) or a load balancer 120, application servers 130, and one or more backend systems 140. Users of clients 150 submit their requests to the web servers 110 through a network 170, such as the Internet.
The ADC 120 distributes clients' 150 requests between the web servers 110 to balance the load. The application servers 130 are often responsible for running the business logic layer of the application and for interacting with various enterprise-wide resources, such as the backend systems 140. The backend systems 140 may include, for example, a database server and a legacy system. Typically, the backend systems 140 operate and respond to requests sent from the clients 150 and forwarded by the application servers 130.
Multi-datacenter systems have been introduced to ensure, in part, scalability and redundancy for web applications. An example for such a system 200 is illustrated in FIG. 2, where 3 datacenters 210-1, 210-2, and 210-3 serve clients 220 through a network 230. Typically, each datacenter is deployed in a different geographic location (site).
The ADC 211 deployed in each datacenter 210 redirects clients' 220 requests to a datacenter that would best serve such requests. Typically, the redirection decision is based on the location of the client. With this aim, an ADC 211 collects “network proximity” information about clients 220 to be used in the distribution decisions. Such information mainly pertains to a location of a client and its network distance from a respective datacenter 220-i. The network proximity information may include static proximity and dynamic proximity details. The static proximity relies on predefined IP-to-location definitions, while the dynamic proximity is based on information collected from the clients 210 by active probes. The probing is performed from one or more datacenters 210, at the same time, to evaluate the network distance (e.g., as a number of router hops) and a round-trip time (RTT) of packets sent from a client 220 to an ADC 211 or vice versa. The data from the probes is consolidated into a proximity database that is usually shared by all ADCs 211 in all the datacenters to maintain a unified and consistent view of client proximity. When a client 220 sends a request to one of the datacenters 210, the ADC 211 of the respective datacenter utilizes the network proximity information and other preferences to decide which of the datacenters 210 should handle the client's 210 request.
Typically, datacenters are expected to meet quality of service (QoS) and quality of experience (QoE) requirements as well as service level agreements (SLAB) when executing an application. Thus, there is a need to monitor transactions in order to prevent situations of, for example, unpredictable levels of service and uncontrolled user experience. One of the factors that determine the QoE is the application responsiveness, i.e., the amount of time that a transaction is completed. That is, the amount of time it takes from when the user sends the request (e.g., clicked on a link or button) to the time that a complete response is received and displayed. The less time it takes, the better the experience is.
The amount of time that it takes to complete a transaction (hereinafter the transaction time (TT)) can be divided into two parts: 1) the time that packets travelled through the network 230, hereinafter the network transaction time (NTT); and 2) the amount of time that a server processes the request(s) to produce the result, hereinafter the server transaction time (STT). Thus, the TT can be computed as follows:TT=NTT+STT.
In the related art, there are tools to measure the NTT and the STT. Such monitoring tools further indicate problems, and provide solutions for solving them. However, conventional monitoring tools that exist today are operative to monitor the TT, STT and NTT only in the datacenter executing the application to be monitored. For example, if an application APPL_1 is executed over a datacenter 210-1, a monitoring tool can measure the TT, STT and NTT value only with respect to the datacenter 210-1 and provide solutions for improving the performance in the datacenter 210-1. For instance, such solutions would include migrating the application to a different application server in the datacenter 210-1 or adding resources to the datacenter 210-1. There is no current solution that can provide an indication of what would be the QoE if the application APPL_1 would have been executed, e.g., at a datacenter 210-2. Further, there are not existing tools that can recommend on the optimal datacenter in terms of cost, SLA, QoE, and QoS for deploying the application.
It would be, therefore, advantageous to provide a system and method that overcomes the deficiencies of existing monitoring tools.